A Service-Oriented Architecture (SOA) is a set of principles and methodologies for design and developing software in the form of interoperable services. SOA also provides a way for consumers of services, such as web-based applications, to be aware of available SOA services. For example, disparate departments within a company may develop and deploy SOA services. Their respective clients can use a defined interface to access the SOA services.
Representing service interface elements in SOA environments can be done via two patterns: an in line pattern and a standards style pattern. Regarding the in line pattern, all elements (e.g., a product, product items, etc.) pertaining to a service (e.g., an online store) may be manifested (e.g., appear) in a same interface, and only the interface may be delivered via a Web Services Description Language (WSDL) file from the service to a consumer. Regarding the standards style pattern, common elements (e.g., a date, a version, and/or a priority, of a service) between services may reside in a library, and the individual services may refer to such common elements. Accordingly, in the standards style pattern, the library including the common elements and the interface of specific service elements (e.g., the WSDL file) may be delivered from a service to a consumer. Due to its reusability and easier implementation, the standards style pattern is often preferred over the in line pattern.
However, the standards style pattern has a direct impact on data optionality, e.g., an ability for service interface elements to be deemed optional instead of mandatory. With respect to the in line pattern, representing data optionality is not difficult as all of the elements are strongly-typed (e.g., manifested in an interface for a specific service), localized, and mandatory. However, with respect to the standards style pattern, representing data optionality creates conflict of interest issues as common elements need to be shared across multiple services. For example, while some of these services may deem the common elements to be optional, others of these services may deem the common elements to be mandatory.
Due to such conflict of interest issues, in the standards style pattern, services may be forced to manifest all of their elements as optional, and specified naming and design rules (e.g., Schematron rules) on the elements are rendered useless. Further, since the elements are required to be optional, a parser of a service cannot validate the elements in service messages as optional or mandatory. Instead, validation is subsequently done at mediation maps of the service. This imposes the risk of absorbing invalid service messages at later layers (e.g., mediation layers) of the service and burdening these later layers, instead of filtering the invalid service messages as early as possible.